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Type  Abstraction  Rules  for  References: 

A  Comparison  of  Four  Which  Have  Achieved  Notoriety 

James  William  O’Toole  Jr." 


Abstract 

I  present  four  type  abstraction  rules  which  have  been 
introduced  by  various  authors  to  permit  polymorphic 
type  safety  in  the  presence  of  mutable  data.  Each  of 
the  type  abstraction  rules  is  discussed  in  the  context  of 
the  language  in  which  is  was  introduced,  and  the  various 
abstraction  rules  are  compared. 

Categories  and  Subject  Descriptions:  D.3.1  [Program¬ 
ming  Languages]  -  Formal  Definitions  and  Theory; 
D.3.3  [Programming  Languages]  -  Language  Con¬ 
structs.  Implicit  Typing,  D.l.m  [Programming  Tech¬ 
niques]  -  Miscellaneous:  Polymorphic  References; 

General  Terms:  Languages,  Type  Theory,  Polymor¬ 
phism,  Reference  Values. 

Additional  Key  Words  and  Phrases:  type  systems,  poly¬ 
morphic  references,  mutation,  effect  systems,  type  infer¬ 
ence,  type  reconstruction,  imperative  types,  weak  poly¬ 
morphism,  Standard  ML,  FX-89. 


1  Type  Abstraction  Rules 

The  type  abstraction  rules  I  consider  here  are: 

1.  FX-89-pure:  expression  abstracted  must  be  pure 

2.  Tofte-applicative:  one-level  store  types 

3.  Damas-III:  two-level  store  types 

4.  MacQueen-weak:  type  variables  have  strength 

2  FX-89-pure 

Attaches  specific  side-effect  information  to  all  function 
arrows  and  enforces  the  correctness  of  these  effect  spec¬ 
ifications.  The  expression  which  is  abstracted  with  re- 
spect  to  a  type  variable  must  have  no  (immediate)  side 
effects. 

This  ought  to  make  it  a  very  restrictive  rule,  as  com 
pared  to  the  others.  (Aside  from  the  fact  that  I  expect 
the  checking  of  the  side-effect  specifications  to  disallow 
more  programs.)  However,  inserting  an  explicit  type  ab¬ 
straction  at  the  appropriate  point  within  the  expression 
might  alleviate  the  problem. 
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2.1  FX-89  Language  Syntax 


L 

:  I 

::=  Identifiers 

TC 

:  P 

:  :=  Primitive  types 

v  : 

:  U 

::=  P  primitive  type 

I  type  identifier 

U  — ►  U  function 

e  : 

E 

:  :=  I 

variable 

(lambda  (I)  E) 

lambda 

(E  E) 

application 

(let  (I  E)  E) 

generic-let 

The  type  domain  U  contains  the  types  which  are  sup- 
r'ied  by  the  programmer  in  explicit  type  declarations. 
The  type  of  a  function  encodes  the  type  of  its  argument 
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and  its  result.  If  the  type  of  the  argument  is  monomor- 
phic,  then  it  may  be  omitted.  The  type  Vt.u  represents 
the  type  of  polymorphic  values  abstracted  over  the  type 
parameter  t. 

In  the  expression  domain,  lambda  abstracts  E  over 
the  ordinary  variable  I. 

2.2  Deductive  System 


where  a\...an  are  the  generic  variables  of  r  £  T. 

The  symbols  V  and  V  are  distinguished  deliberately: 

V  binds  the  generic  type  variables  of  a  type  scheme,  and 

V  binds  type  variables  within  a  type. 

Definition  (Alpha-renaming).  Types  r  and  r  are 
alpha-renamable  (written  r  ~  r')  iff  some  renaming  of 
type  variables  bound  in  r  produces  r'. 


I  present  the  typing  system  of  IFX  as  as  formal  deduc¬ 
tion  system  consisting  of  a  set  of  type  reconstruction 
rules.  The  type  system  contains  generic  (i.e.  general) 
typo  v-.r  •>b!es,  and  distinguishes  between  these  generic 
type  variables  and  the  type  identifiers  which  appear  in 
user-supplied  types.  The  type  system  also  distinguishes 
between  monomorphic  and  polymorphic  types: 


a  :  G 
y.  :  M 


t  :  T 


General  type  variables 

P  primitive  type 

I  type  identifier 

G  general  type  variable 

M  — *  M  function 

P  primitive  type 

I  type  identifier 

G  general  type  variable 

T  — »  T  function 

Vli...I„.T  polymorphic  type 


The  IFX  typing  rules  make  use  of  an  important  dis¬ 
tinction  between  the  M  and  T  type  domains.  The  rules 
are  designed  so  that  M  types  may  be  omitted  from 
formal  argument  type  declarations,  but  T  types  may 
not.  Thus,  the  different  levels  in  the  type  syntax  spec¬ 
ify  the  restrictions  on  the  input  programs.  The  use  of 
syntactically-specified  restrictions  is  intended  to  com¬ 
municate  clearly  to  the  programmer  the  limitations  of 
the  type  reconstruction  system. 


Type  Schemes 

The  IFX  type  system  supports  the  generic  polymor¬ 
phism  found  in  ML,  as  well  as  the  explicit  polymorphism 
found  in  Reynolds’  second-order  polymorphic  lambda 
calculus.  In  order  to  provide  generic  polymorphism, 
type  schemes  are  defined  which  represent  the  generic 
(i.e.  general)  type  of  a  variable  which  is  permitted  mul¬ 
tiple  instantiations-. 


Definition  (Type  Scheme).  A  type  scheme  r)  is  a 
term  of  the  form 

Va1...o„.r, 


Definition  (Instantiation).  The  type  r'  is  an  in¬ 
stance  of  the  scheme  rj  —  Vai...a„.r  (written  n  V  r'\  iff 
there  are  monomorphic  y\...yn  such  that  r[/ii/a,j  ~  r' . 
(The  y  relation  extends  to  type  schemes  by  ij  y  if  iff 
Vr  :  T}'  y  t  rj  X  t  .) 


Note  that  only  M  types  may  be  substituted  to  produce 
instantiations,  and  that  it  is  assumed  that  substitution 
takes  place  with  renaming  of  any  bound  type  variables 
to  avoid  capture.  The  result  of  substituting  y  for  t  in 
r  will  be  written  T[y/t].  The  type  scheme  rj  =  V  r, 
having  no  generic  type  variables,  will  occasionally  be 
abbreviated  as  r. 

The  inference  rules  for  explicitly  typed  terms  are  pre¬ 
sented  first.  A  type  assignment  A  maps  each  variable  in 
its  domain  to  a  type  scheme.  The  notation  Ar  refers  to 
the  type  assignment  A  with  the  assignment  for  variable 
x  removed. 

The  notation  FGV(r)  refers  to  the  free  general  type 
variables  of  r,  and  FTV(r)  to  refer  to  the  free  type  iden¬ 
tifiers  of  r.  Similarly,  FGV(A)  refers  to  the  free  general 
type  variables  of  the  type  schemes  in  the  assignment  A. 
Also,  Gen (A,r)  is  defined  as  follows: 


Definition  (Generalization).  The  generalization 
of  t  with  respect  to  A  (written  Gen(j4,r)),  is  the  type 
scheme  *7  =  Vo j.r,  where  {a,-}  =  FGV(r)  —  FGV(A). 


Typing  Rules 


The  type  reconstruction  rules  of  IFX  are  as  follows: 


ILAMBDA 


Ax  +  (x  :  y)  e  :  r 
A  b  (lambda  (z)  *,)  :  y  — *  r 
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APPL 


3.1  Definitions 


A  h  e  :  ra  — *■  rr 
A  h  e„  :  ra 
A  l~  (e  ea)  :tt 

The  above  rules  describe  the  typing  requirements  of 
value  abstraction  and  value  application. 

The  following  rules  describe  the  typing  requirements 
of  variables  and  the  ML-style  generic  let  construct. 

VARINST 

(x  :  Va,.r)  £  A 
Ah  x  :  rfa/ati] 

ILET 

A  h  et  :  n 

A  h  et,  :  r£  =>  Gen(A,i>)  V  Gen(A,Tj) 

At  +  (x  :  Gen(A,  i),))  he:  r 
A  h  (let  ( x  e4)  e )  :  r 


Generic  let 

The  ILET  and  VARINST  rules  provide  the  ML-style 
generic  let.  ILET  associates  a  generic  type  scheme 
with  the  let-bound  variable,  and  VARINST  permits 
each  occurence  of  the  variable  to  be  independently  as¬ 
signed  any  instance  of  its  generic  type  scheme.  The 
convenience  of  automatic  generalization  and  instantia¬ 
tion  are  provided  by  these  two  rules.  In  IFX,  the  typing 
rules  permit  this  convenience  with  the  caveat  that  the 
automatically  deduced  type  parameters  be  M  types. 

The  typing  power  of  the  ILET  rule  is  equivalent  to 
that  provided  by  rewriting  the  1st  expression  in  the 
usual  way,  while  making  use  of  open  and  close: 

((lambda  (x  :  r)  e[(open  x)/x])  (close  ei)). 

However,  this  transformation  is  not  pure  syntactic 
sugar,  because  it  requires  r,  the  explicitly  polymorphic 
type  of  the  bound  variable. 


The  typing  system  distinguishes  between  imperative  and 
applicative  type  variables: 

t  e  AppTyVar 
u  £  ImpTyVar 

a  gTyVar  —  AppTyVar  U  ImpTyVar 


r  :  K 


P  primitive  type 

G  type  variable 

H  — ►  H  function 
r  ref  reference  type 


Definition  (Type  Closure).  The  type  closure  of  r 
with  respect  to  A  (written  Closer),  is  the  type  scheme 
rj  =  Vai.T,  where  {a,}  =  tyvais  r  —  tyvars  A. 


Definition  (Applicative  Type  Closure).  The  ap¬ 
plicative  type  closure  of  r  with  respect  to  A  (written 
AppCloe^rj,  is  the  type  scheme  rj  =  Vor,.r,  where 
{a<}  =  apptyvars  r  —  apptyvars  A. 


When  a  type  scheme  is  instantiated,  only  imperative 
types  may  be  substituted  for  imperative  type  variables. 
An  expression  is  considered  to  be  expansive  if  its  evalua¬ 
tion  might  expand  the  domain  of  the  store  (i.e.,  allocate 
mutable  data).  The  classification  adopted  in  [Tofte87] 
is  that  1st  expressions  and  applications  are  expansive, 
but  lambda  abstractions  and  variable  accesses  are  not. 


3.2  Typing  rules 


The  reference  creation  operator  rel  is  assigned  the  im¬ 
perative  type  Vu.u  —*  uref.  The  rules  which  provide 
type  abstraction  of  expansive  and  non-expansive  ex¬ 
pressions  in  the  imperative/applicative  system  are  as 
follows: 


3  Tofte-applicative 

Contaminates  all  type  variables  appearing  in  any  type 
expression  at  which  the  ref  constructor  is  instantiated. 
The  contaminated  type  variables  are  imperative,  the 
others  are  applicative.  This  distinction  is  maintained 
by  type  abstraction,  and  is  enforced  at  function  call 
boundaries,  etc.  The  abstraction  rule  does  not  permit 
abstractions  of  expansive  expressions  with  respect  to 
imperative  type  variables;  expansive  expressions  are  let 
and  application  expressions. 


VARINST 

(x  :  Vq,  .t)  €  A 
Ah  x  :  rfri/ati] 

LET-Expansive 


A  h  e»  :  n 
is  expansive. 

Ax  -b  (x  :  AppClos^n)  h  e  :  r 
A  I-  (let  (x  e»)  e)  :  r 
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LET-Non-expansive 


A  (written  DClos^Ar;),  is  the  type  scheme  r/'  =  Vo,.!/, 
where  {a,}  =  tyvars  rj  —  (tyvars  Atyvars  A. 


A  F  e4  :  n 

IS  uOii-CXp<*IlEIV6. 

Ax  +  (x  :  cios^n)  F  e.  :  r 
A  F  ti«t  ( x  ej)  e)  :  r 

3.3  Applicative  Types  and  FX-89 

In  FX-89,  type  abstraction  is  permitted  only  when  the 
side-effect  specifications  ensure  that  the  polymorphic 
expression  is  referentially  transparent.  [Tofte87]  takes  a 
different  approach,  based  on  the  concept  of  applicative 
types.  Tofte  classifies  certain  expressions  as  expansive, 
and  permits  type  abstraction  of  these  expressions  only 
with  respect  to  applicative  type  variables.  This  type  ab¬ 
straction  rule  permits  different  type  abstractions  than 
does  the  FX  89  pure-type-abstraction  rule,  as  I  will 
show  later.  Perhaps  the  imperative  typing  discipline 
can  be  combined  with  the  type  reconstruction  system 
of  FX-89. 


4  Damas-III 

Maintains  a  two  level  version  of  imperative  types,  distin¬ 
guishing  those  type  variables  which  have  been  contam¬ 
inated  already  from  those  which  will  become  contami¬ 
nated  by  further  application.  The  deductions  carry  a 
set  of  type  variables,  and  so  also  do  any  type  schemes 
which  are  arrows.  Types,  however,  do  not  carry  sets  of 
type  variables,  nor  is  there  more  than  a  single  top-level 
such  set  in  a  type  scheme. 

4.1  Definitions 

The  typing  system  defines  schemes  to  include  a  set  of 


type  variables: 

a  €  TyVar 

r  :  T  :  :  = 

P 

primitive  type 

G 

type  variable 

T  — *  T 

function 

r  ref 

reference  type 

V  :  S  ::= 

T 

type 

T  — *  T  *  A  impure  function 

Va  rj 

polymorphic  typ 

Definition  (Type  Closure).  The  type  closure  of  t) 
with  respect  to  type  assignment  A  and  type  variables 


When  a  type  scheme  is  instantiated,  the  substitution 
is  used  to  expand  the  set  of  type  variables,  and  the  set 
of  type  variables  may  be  spuriously  expanded  as  well. 

4.2  Typing  rules 

The  reference  creation  operator  ref  is  assigned  the  im¬ 
perative  type  'it.t  —*tref*{t).  The  rules  which  pro¬ 
vide  type  abstraction  and  instantiation  arc  as  follows. 

DVARINST 

(x  :  Vori.r)  6  A 
A  F  x  :  ]  *  <t> 

DLET 

A  F  ej,  :  T)b  *  A 

Ax  +  (x  :  DClos^Vi)  F  e  :  r;  *  A 
A  F  (let  (r  tj)  e)  :  rj  *  A 

The  rules  which  describe  the  typing  requirements  of 
value  abstraction  and  value  application  are  as  follows: 

DLAMBDA 

A~  +  (x  :  r0)  F  e  :  r  *  A 
A  F  (lambda  (x)  e)  :  (ra  — ►  r  *  A)  *  <t> 

DAPPL 

A  F  e  :  (r0  —  rr)  *  A 
A  F  ea  :  ra  *  A 
AF(e  ea)  :  rr  *  A 

5  MacQueen-weak 

Attaches  numbers  to  type  variables  which  measure  their 
“weakness”  (strength).  The  numbers  indicate  how- 
many  applications  must  take  place  before  a  reference  to 
the  type  variable  might  have  been  created.  Abstraction 
is  permitted  only  with  respect  to  type  variables  whose 
weakness  remains  positive.  Weakness  is  downward  con¬ 
taminating,  and  the  reference  constructor  is  the  source 
of  contamination.  A  further  restriction  is  not  yet  well 
understood:  An  instantiation  of  a  let-bound  variable  is 
strength-limited  somehow,  related  to  the  outermost  ab¬ 
straction  level  at  which  the  expression  of  which  it  is  pari 
appears  as  an  operand.  Better  figure  this  out. 


5.1  Definitions 

The  typing  system  distinguishes  between  imperative  and 
applicative  type  variables: 

w  €  Strength  =  1,0, 1, ...,  oo} 

a  £Tyvar 

aw  G  WeakTyV ar  =  TyVar  x  Strength 

r  :  M  : :  =  P  primitive  type 

G  type  variable 

H  — ♦  H  function 
r  ref  reference  type 

Definition  (Strength  Limit).  The  type  r  is  w- 
strength  limited,  written  [r]“,  iff  all  type  variables  in 
r  with  non-infinite  strength  have  strength  less  than  or 
equal  to  w. 

Definition  (Strengthening).  The  strengthening  of  r, 
written  [r]++,  is  the  type  in  which  all  type  variables 
with  non-infinite  strength  have  incrementally  larger 
strength.  So  [ra  — *•  =  [ra]++  —►  [rt]++,  and 

[q°°]++  =  a°°,  but  [<*“’]++  =  aw+1. 

Definition  (Weak  Type  Closure).  The  weak  type 
closure  cf  r  with  respect  to  A  (written  WeakClos^r),  is 
the  type  scheme  t)  —  Va‘",.r,  where  {<*<}  =  tyvars  r  — 
tyvars  A,  and  Wi  —  min{u)|a"  €  tyvars  r). 

When  a  type  scheme  is  instantiated,  the  type  substi¬ 
tuted  for  a  type  variable  must  not  be  stronger  than  the 
type  variable. 

Weak  Typing  Rules 

The  type  reconstruction  rules  of  MacQueen-weak  are  as 
fallows: 

WLAMBDA 

Ax  +  (z  :  ft)  h  e  :  r 
A  I-  (lambda  (x)  e)  :  [/i  — ►  r]++ 

WAPPL 

Ah  e  :[ra  —>  rr]++ 

A  h  e,  :  ra 

_ N° 

Ah  (e  ea)  :rr 

The  above  rules  describe  the  typing  requirements  of 
value  abstraction  and  value  application. 


The  following  rules  describe  the  typing  requirements 
of  variables  and  the  ML-style  generic  let  construct. 

WINST 

(x:Va“‘.r)eA 

_ tejr 

A  h  z  :  rfo/a;] 

WLET 

Ah  et  :  n 

Ax  +  (x  :  WeakClos^Ti)  h  e  :  r 
A  h  (let  (x  e»)  e)  :  r 

The  reference  value  constructor  rel  is  assigned  the 
type  Va'.a1  — >  a1  ref. 

6  Comparison  of 
Abstraction  Rules 

6.1  Damas-III  >  Tofte-applicative 

(1)  let  f  -  let  x  =  (fn  x  =>  x)  1 
in  (fn  y  ~>  ! (ref  y ) ) 
end 

in  (f  1;  f  true) 
end 

[Tofte87]  provides  this  example  on  page  73. 

Damas-III  can  type  this  system  because  the  let  ex¬ 
pression  defining  f  is  abstractable  with  respect  to  the 
type  of  y.  This  is  the  case  because  the  two-level  analysis 
of  the  allocated  types  of  the  let  expression  reveals  that 
none  are  already  allocated,  although  the  type  of  y  wih 
be  allocated  by  further  application. 

Tofte-applicative  cannot  type  this  system  because  the 
one-level  analysis  reveals  merely  that  the  type  of  y  is  or 
will-be  allocated,  and  the  let  expression  is  considered 
expansive,  so  the  type  abstraction  is  not  permitted. 


6.2  Tofte-applicative  >  Damas-III 

(2)  No  known  example. 

[Tofte87]  states  on  page  73  that  an  embedding  exists. 
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6.3  MacQueen-weak  > 

Tofte-applicative,  Damas-III 


let  fold  =  fn  f  =>  fn  i  =>  fn  1  => 
let  data  =  ref  1 
result  =  ref  i 
in  (while  ((data  <>  □)  do 

(result  :=  f (hd( !data)) ( ! result) 
data  :=  tl(!data)); 

(result) 


end 

in  let  fastjreverse  =  fold  cons  □ 
in  (f a.'st.reverse  [3,5,7]; 

fastjreverse  [true, true, f alse] ) 

end 


end 


[Tofte87],  Example  4.5,  mentioned  on  page  74. 

MacQueen-weak  can  type  this  example,  because  the 
counting  methods  used  by  the  typing  algorithm  deduce 
that  fold  must  be  applied  three  times  before  any  al¬ 
location  occurs,  and  since  fast_reverse  is  defined  by 
applying  fold  only  twice,  f  ast  .reverse  still  has  a  type 
of  strength  one,  and  so  may  be  generalized  with  respect 
to  the  type  of  the  elements  of  the  list. 

Tofte-applicative  cannot  type  this  example  because 
the  one-level  store  typing  analysis  considers  the  expres¬ 
sion  (fold  cons  □)  to  be  expansive,  and  therefore 
does  not  permit  the  type  abstraction. 

Damas-III  cannot  type  this  example  because  the  two- 
level  method  also  considers  all  type  variables  to  have 
been  allocated  by  the  evaluation  of  (fold  cons  □), 
and  therefore  does  not  permit  the  necessary  type  ab¬ 
straction. 


6.4  Damas-ITI,  Tofte-applicative  > 
MacQueen-weak 

(4)  1st  rid  =  fn  x  =>  ! (rsf  x) 

in  1st  f  =  fn  y  =>  rid  (fn  a  =>  a)  y 
in  (f  0; 
f  true) 

end 

end 

Tofte-applicative  can  type  this  example,  because  the 
defining  expression  for  f  is  a  lambda  abstraction,  which 
is  considered  non-expansive,  and  so  the  type  abstraction 
with  respect  to  the  type  of  y  is  permitted  even  though 
it  is  an  imperative  type.  (Damas-III  can  also  type  this 


example  because  the  two-level  analysis  also  reveals  that 
the  lambda  expression  defining  f  has  not  yet.  allocated 
at  any  types.) 

MacQueen-weak  cannot  type  this  example,  because 
rid  must  be  given  a  type  with  strength  one,  and  yet  rid, 
sifter  instantiation,  is  applied  twice.  This  lowers  the 
strength  so  that  the  strength  of  the  type  of  y  becomes 
zero.  Therefore,  the  type  abstraction  is  not  permitted. 

6.5  FX-89-pure  >  Damas-III, 
Tofte-applicative,  MacQueen-weak 

(5)  let  nop  =  fn  f  =>  fn  x  => 

let  g  =  fn  y  =>  f  x 
in  x 
end 

in  let  h  -  ncp  (fn  a  =>  !(ref  a)) 

(fn  b  =>  b) 

in  (h  0; 
h  true) 

end 

end 

FX-89-pure  can  type  this  example  because  the  side- 
effect  analysis  system  correctly  determines  that  nop  has 
no  latent  side-effects,  because  the  evaluation  of  nop  ap¬ 
plied  to  any  arguments  f  and  x  will  merely  return  x.  If 
1  were  applied  by  nop,  then  the  latent  effect  of  the  type 
of  nop  would  include  the  latent  effect  of  its  argument 
type,  the  type  of  f .  Therefore,  the  defining  expression 
for  h  is  pure,  and  may  be  abstracted  with  respect  to  the 
type  of  b. 

Damas-III  and  Tofte-applicative  cannot  type  this  ex¬ 
ample  because  the  store-typing  analysis  methods  as¬ 
sume  that  allocation  has  occured  at  the  type  of  a  during 
the  evaluation  of  the  defining  expression  for  h  (the  ap¬ 
plication  of  nop).  The  binding  of  g  in  the  definition  of 
nop  constrains  the  type  of  a  to  be  the  same  as  the  type 
of  b.  Therefore,  type  abstraction  with  respect  to  the 
type  of  b  is  not  permitted. 

MacQueen-wcak  cannot  type  this  example  because 
the  maximum  weakness  permitted  for  the  type  of  a  is 
zero,  because  it  is  an  operand  of  nop.  Therefore,  the 
type  of  b  is  forced  to  strength  zero  and  the  type  ab¬ 
straction  is  not  permitted.  My  intuition  for  this  is  that 
nop  is  presumed  to  apply  its  arguments  completely. 

6.6  Damas-III,  Tofte-applicative, 
MacQueen-weak  >  FX-89-pure 

(6)  let  k  =  fn  a  => 
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let  r  =  ref  a 
in  fn  b  =>  !r 
•nd 

in  let  f  =  k  □ 
in  (f  0; 
f  true; 
false) 

end 

end 

Damas-III,  Tofte-applicative,  and  MacQueen-weak 
can  type  this  example  because  the  defining  expression 
for  f  can  be  abstracted  with  respect  to  the  type  of  b. 
All  three  systems  will  not  permit  abstraction  with  re¬ 
spect  to  the  type  of  a,  because  an  allocation  at  that 
type  will  have  occured.  However,  this  does  not  prevent 
the  other  abstraction,  because  the  types  of  a  and  b  are 
not  related. 

FX-89-pure  cannot  type  this  example  because  the  ab¬ 
straction  rule  requires  that  no  allocations  have  taken 
place,  and  does  not  distinguish  between  the  type  vari¬ 
ables  at  which  allocations  have  tak**n  place  and  the  type 
variables  at  which  no  allocation  have  (or  will)  occur. 

6.7  Further  Speculation 

However,  the  above  example  will  be  typed  by  FX-89- 
pure  if  an  explicit  abstraction  is  inserted  within  the  def- 
iR'.t.--n  of  k.  It  u  ulsu  tc  observe  mat  even 

with  an  explicit  type  abstraction  in  the  definition  of  k, 
it  will  not  be  possible  to  give  f  a  generic  type,  because 
of  the  pure-abstraction  rule.  Yet  f  will  be  automati¬ 
cally  projected  as  required  in  this  example,  and  f  can 
tc  opened  explicitly  as  well.  Special  casing  the  abstrac¬ 
tion  rule  in  1st  to  permit  generalization  by  opening 
would  circumvent  this  peculiarity,  although  it  will  not 
eliminate  the  need  for  explicit  abstractions. 

Also,  I  do  not  expect  explicit  abstractions  to  solve 
this  problem  in  general.  Including  types  in  alloca¬ 
tion  (and  perhaps  other)  effects,  and  relaxing  the  pure- 
abstraction  rule  to  examine  the  side  effects  and  selec¬ 
tively  permit  type  abstractions  should  provide  a  much 
more  general  treatment  of  this  problem.  I  call  this  the 
“Alloc®!”  typing  system.  This  system  is  essentially 
the  system  which  is  mentioned  in  [Damas85]  on  pages 
90-91,  where  he  observes  that  attaching  sets  of  types  to 
type  arrows  will  complicate  the  unification  algorithm 
for  types.  Damas-III  therefore  attaches  a  set  of  types 
to  type  scheme  arrows  and  also  a  set  of  types  to  typing 
assertions.  Tofte-applicative  may  be  viewed  as  attach¬ 
ing  a  single  set  of  types  to  type  schemes. 


7  Summary 

Damas-III  is  strictly  superior  to  Tofle-applicative,  but 
MacQueen-weak  and  FX-8C  pure  are  incomparable  to 
either  of  the  above.  Tofte  has  suggested  in  [Tofte89]  that. 
MacQueen-weak  is  strictly  superior  toTofte-applicativ'-, 
but  this  is  not  the  case  (see  example  (4)). 

Appendix  (sml) 

Examples  provided  in  sml  syntax. 

(1)  let  val  f  =  let  val  x  =  (fn  x  =>  x)  1 

in  (fn  y  =>  !  (ref  y)) 
end 

in  (f  1;  f  true) 
end; 

(2)  No  known  example. 

(3) 

let  fun  fold  f  i  1  = 

let  val  data  =  ref  1 
and  result  =  ref  i 
in  srhile  (!data  <>  □ )  do 

(result  :=  f(Hd  ( 'data) ) ( ! result 
data  :=  tl(!data) 

); 

!  result 

and 

and  cons  a  b  =  a: :b 
val  fastjreverse  =  fold  cons  □ 
in  fast_reverse  [3,5,7]; 

fast_reverse  [true, true, false] 
end; 

(4)  let  fun  id  x  =  x 

and  rid  x  =  ! (ref  x) 
fun  f  y  *  rid  id  y 
in  (f  0; 
f  true) 

end; 

(5)  let  fun  id  b  =  b 

and  rid  a  =  ! (ref  a) 
and  nop  f  x  = 

let  fun  g  y  =  f  x 
in  x 
end 

val  h  =  nop  rid  id 
in  (h  0; 


7 


h  trus) 

and; 

(6)  lat  fun  ka  = 

lat  val  r  =  raf  a 
in  fn  b  =>  !r 
and 

val  f  =  k  □ 
in  (f  0; 

f  trua; 
falsa) 

and; 


Appendix  (fx) 

Examples  provided  in  FX-89  syntax. 

(1) 

(let  ((f  (let  ((x  ((lambda  (x)  x)  1))) 

(lambda  (y)  (get  (new  y)))))) 

(begin 
(f  1) 

(f  #t))) 

(2)  No  known  example. 

(3) 

(lat  ((fold  (lambda  (f  i)  (lambda  (1) 

(lat  ((data  (new  1)) 

(rasult  (naw  l))) 
loagia 

(whila  (not  (null?  (gat  data))) 
(begin 

(sat  rasult  (f  (car  (gat  data)) 
(gat  result))) 
(sat  data  (cdr  (gat  data))))) 
(get  result)))))))) 

(let  ((fast_reversa  (fold  cons  nil))) 

(begin 

(f astjreverse  (list  3  6  7)) 

(fast_rever8e  (list  #t  #t  #f))))) 

(4)  (let  ((id  (lambda  (x)  x)) 

(rid  (lambda  (x)  (get  (new  x))))) 
(lat  ((f  (lambda  (y)  ((rid  id)  y)))) 
(begin 
(f  0) 

(f  #t)))) 


(6) 

(lat  ((id  (lambda  (b)  b)) 


(rid  (lambda  (a)  (get  (new  a)))) 

(nop  (lambda  (f) 

(lambda  (x) 

(let  ((g  (lambda  (y)  (f  *)))> 
x))))) 

(lat  ((b  ((nop  rid)  id))) 

(begin 

(h  0) 

(h  #t)))) 

(6)  (lat  ((k  (lambda  (a) 

(let  ((r  (new  a))) 

(lambda  (b)  (get  x) ))'/)) 
(let  ( (f  (k  nil)) ) 

(begin 
(f  0) 

(f  #t) 

#f))) 
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